home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970929-19971216 / 000257_news@newsmaster….columbia.edu _Thu Nov 13 12:46:58 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  9KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id MAA25186
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 13 Nov 1997 12:46:57 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id MAA03173
  7.     for kermit.misc@watsun; Thu, 13 Nov 1997 12:46:57 -0500 (EST)
  8. Path: news.columbia.edu!panix!logbridge.uoregon.edu!su-news-hub1.bbnplanet.com!news.bbnplanet.com!news1.best.com!noos.hooked.net!news.scruz.net!usenet
  9. From: Jon Shemitz <jon@midnightbeach.com>
  10. Newsgroups: alt.lang.delphi,aus.electronics,comp.dcom.modems,comp.home.automation,comp.lang.pascal.delphi.misc,comp.protocols.kermit.misc,sci.electronics.design
  11. Subject: Re: Xmodem specs required
  12. Date: Thu, 13 Nov 1997 09:31:31 -0800
  13. Organization: Midnight Beach
  14. Lines: 153
  15. Message-ID: <346B3973.244AB2B0@midnightbeach.com>
  16. References: <64f01j$cno@granny.mac.co.nz>
  17. Reply-To: jon@midnightbeach.com
  18. NNTP-Posting-Host: 165.227.113.198
  19. Mime-Version: 1.0
  20. Content-Type: text/plain; charset=us-ascii
  21. Content-Transfer-Encoding: 7bit
  22. X-Mailer: Mozilla 4.02 [en] (Win95; U)
  23. To: huisman <minilinx@netaccess.co.nz>
  24. Xref: news.columbia.edu alt.lang.delphi:19542 aus.electronics:8562 comp.dcom.modems:204910 comp.home.automation:36058 comp.lang.pascal.delphi.misc:131315 comp.protocols.kermit.misc:8040 sci.electronics.design:59280
  25.  
  26. huisman wrote:
  27.  
  28. > I'm not sure which is best group for data communications but
  29. > does anyone have information regarding Xmodem protocol.
  30. > I am wanting to write 8051 code for data logger to communicate
  31. > with PC.(PC end will be Win 95 (Delphi 2 ) app.
  32.  
  33.  
  34.                         MODEM/XMODEM Protocol Explained
  35.  
  36.                                        by
  37.  
  38.                          Kelly Smith, CP/M-Net "SYSOP"
  39.  
  40.                                  January 8,1980
  41.  
  42.  
  43.  I  thought that it may be of some interest to those of  you that  use  the 
  44. MODEM/XMODEM file transfer capability of  the CP/M-Net,  to get a little 
  45. insight as to the  communications protocol  (i.e.  "handshaking  method") used 
  46. by the  system. 
  47.  
  48.  Herein  lies the details of a very good (not perfect)  data communications  
  49. protocol  that  has become  the  "de  facto" standard  for various remote CP/M 
  50. systems (RCPM's) that  are accessible across the country (refer to RCPMLST4.DOC 
  51. on  all RCPM's  for access numbers and note that the "digit  number" in that 
  52. list changes as new system are listed).  I also wish to give credit to Ward 
  53. Christensen (the "original" CBBS) for writing  MODEM.ASM (CPMUG Volume 25.11) 
  54. and Keith  Petersen, Bruce Ratoff, Dave Hardy, Rod Hart, Tom "C" (we know who 
  55. you are Tom!),  and others,  for enhancements to Ward's original program that
  56. we now call XMODEM (external modem).
  57.  
  58.  Data is sent in 128 byte blocks with sequentially  numbered blocks, and 
  59. appended by a single checksum at the end of each block. As the receiving 
  60. computer acquires the incoming data, it  performs it's own checksum and upon 
  61. each completion of a block,  it  compares it's checksum result with that  of  
  62. the sending  computers.  If  the receiving computer matches  the checksum of 
  63. the sending computer, it transmits an ACK (ASCII code protocol character for 
  64. ACKNOWLEDGE (04 Hex, Control-F)) back to the sending computer.  The ACK 
  65. therefore means "alls well  on  this  end,  send  some  more...".  Notice  in  
  66. the following example,  that the sending computer will  transmit an  "initial  
  67. NAK"  (ASCII protocol character  for  NEGATIVE ACKNOWLEDGE (15 Hex,  
  68. Control-U))...or,  "that wasn't  quite right, please send again". Due to the 
  69. asynchronous nature of the  initial  "hook-up"  between  the  two  computers,   
  70. the receiving  computer  will "time-out" looking for  data,  and send the NAK 
  71. as the "cue" for the sending computer to  begin transmission. The  sending 
  72. computer knows that the receiving computer  will  "time-out",  and uses this 
  73. fact to  "get  in sync"...The  sending computer responds to the "initial  NAK" 
  74. with  a  SOH  (ASCII code protocol character  for  START  OF HEADING (01 Hex,  
  75. Control-A)), sends the first block number, sends the 2' complement of the block 
  76. number (VERY important, I will discuss this later...), sends 128 bytes of 8 bit
  77. data (thats  why  we can transfer ".COM" files),  and  finally  a checksum,  
  78. where  the checksum is calculated by summing  the SOH,  the block number, the 
  79. block number 2's complement, and the 128 bytes of data.
  80.  
  81. Receiving Computer:
  82.  
  83. ----/NAK/------------------------/ACK/----------------------
  84.      15H                          06H 
  85.  
  86. Sending Computer:
  87.  
  88. --------/SOH/BLK#/BLK#/DATA/CSUM/---/SOH/BLK#/BLK#/DATA/etc.
  89.          01H 001H 0FEH 8bit 8bit     01H 002H 0FDH 8bit ....
  90.  
  91.  This  process continues,  with the next 128 bytes,  IF  the block  was ACK'ed 
  92. by the receiving computer,  and  then  the next sequential block number and 
  93. it's 2's complement, etc.
  94.  
  95.  But  what  happens  if the  block  is  NAK'ed?...easy,  the sending computer 
  96. just re-sends the previous block.  Now  the hard  part...what if the sending 
  97. computer transmits a block, the  receiving computer gets it and sends an  ACK,
  98. but  the sender  does not see it?...The sending computer thinks  that it   has  
  99. failed  and  after  10  seconds  re-transmits  the block...ARGH!...the  
  100. receiving  computer has  "stashed"  the data  in  memory or on disk (data is 
  101. written to  disk  after receiving 16 blocks),  the receiving computer is now 1 
  102. block AHEAD of the transmiting computer!  Here comes the operation of the block 
  103. numbers...The receiver detects that this is the last  block  (all over again),  
  104. and transmits back  an  ACK, throws   away   the  block,   and   (effectively)   
  105. "catches up"...clever!  Whats more, the integrity of the block number is 
  106. verified by the receiving computer, because it "sums" the SOH  (01 Hex) with
  107. the block number plus the 2's  complement of  the  block number),  and the
  108. result MUST BE zero  for  a proper  transfer  (e.g.  01+01+FE hex =  00,  on
  109. the  first block). The sequence of events then, looks like this:
  110.  
  111. Receiving Computer:
  112.  
  113. ----/ACK/-----------------------/NAK/-----------------------
  114.      06H                         15H  
  115.  
  116. Sending Computer:
  117.  
  118. CSUM/---/SOH/BLK#/BLK#/DATA/CSUM/---/SOH/BLK#/BLK#/DATA/etc.
  119. 8bit     01H 003H 0FCH 8bit 8bit     01H 003H 0FCH 8bit ....
  120.  
  121.  Normal completion of data transfers will then conclude with an  EOT (ASCII 
  122. code protocol END OF  TRANSMISSION,  04  Hex, Control-D)  from the sending 
  123. computer,  and a final ACK from the  receiving computer.  Unfortunately,  if  
  124. the  receiving computer  misses the EOT,  it will continue to wait for  the 
  125. next block (sending NAK's every 10 seconds,  up to 10 times) and eventually 
  126. "time-out".  This is rarely the case however, and  although  not  
  127. "bullet-proof",  it is a  very  workable protocol.
  128.  
  129. Receiving Computer:
  130.  
  131. ----/ACK/---/ACK/"Transfer Complete"/A>(or B>)
  132.      06H     06H ................................
  133.  
  134. Sending Computer:
  135.  
  136. CSUM/---/EOT/---/A>(or B>)
  137. 8bit     04H .............
  138.  
  139.  In   some  case,   where  the  telephone  transmission   is repeatedly  
  140. "trashed" (weak signals,  multiple noise "hits", etc.),   the  receiving  
  141. computer  (and  operator)  will  be provided the option to quit.  Here,  the 
  142. operator enters "R" or  "Q" in response to "Retry or Quit?" (after 10  
  143. retries), and  if quit is envoked by the operator,  a CAN (ASCII  code protocol 
  144. CANCEL, 18 Hex, Control-X) is sent by the receiving computer to cancel the 
  145. entire transfer session (Note:  is is possible   to  "garble"  an  ACK  to  a   
  146. CAN,   and   abort prematurley):
  147.  
  148. Receiving Computer:
  149.  
  150. ----/NAK/...NAK's ten times.../"Retry or Quit?"(Q)/CAN/A>...
  151.      15H                                           18H
  152.  
  153. Sending Computer:
  154.  
  155. CSUM/---/...Garbled Data....../-----------------------/A>...
  156. 8bit
  157.  
  158.  A final considerations when using the MODEM program,  is  a timing related
  159. problems when transfer status messages and/or textual  data is directed to the 
  160. screen of a slow (4800 Baud or less) terminal or to a hard copy printer. This 
  161. problem is readily  apparent (multiple NAK's) when using MODEM for  the first 
  162. time, and can usually be "cured" by NOT SPECIFYING the "V"  (video)  sub-option 
  163. when sending  or  receiving  files. Users  of  Lifeboat  Associates  BSTAM  
  164. encounter  the  same problem, but this is easily fixed with the files 
  165. TQPATCH.ASM and  RQPATCH.ASM  (transfer quiet/receive quiet) that  Keith 
  166. Petersen (Royal Oak CP/M,  "call-back" remote system, (313)- 588-7054)  wrote 
  167. to solve the problem of low speed  terminal I/O.
  168.  
  169.  For users of CBBS's that do not have MODEM.ASM (but DO HAVE a  CP/M disk 
  170. system...ESSENTIAL!),  let me suggest that  you "data  capture" the file 
  171. MBOOT3.ASM from one of  the  RCPM's (it's  a small 8 kilo-byte file that "fits" 
  172. in most system's memory) to get the larger MODEM.ASM (40  kilo-bytes).  Check 
  173. it  very carefully for errors using the "data capture" (read ERROR  PRONE 
  174. method here).  Then edit and assemble for  your modem  configuration.
  175.  
  176.  If  you are tired of buying software where the advertisment is written better 
  177. than the program, then the RCPM's are just what you have been looking for...and 
  178. FREE!